This fixes a regression introduced by creating autopatch internal GET/PUT requests with the incoming request context.

Using http.NewRequestWithContext(ctx.Context(), ...) preserves user context values, but with humachi it also preserves chi.RouteContext. When autopatch serves the internal GET/PUT through the same adapter/router, chi sees an existing route context and reuses stale routing state from the outer PATCH request. As a result, the internal GET can be routed back to the generated PATCH handler, causing recursion and eventually a panic when the nested request has no body.

Example failure:

PATCH /resource/{id}
autopatch -> internal GET /resource/{id}
chi reuses outer RouteContext with PATCH route state
internal GET hits PATCH handler again
io.ReadAll(nil) panic

Fix

Wrap the incoming context for autopatch internal requests and filter out chi.RouteCtxKey, while preserving all other context behavior and values.

This keeps the intent of #1019:

request-scoped context values are still available;
cancellation and deadlines are preserved;
router-specific state from chi is not leaked into nested internal requests.

Notes:

This is my first PR to a community-driven library, so I may have missed some project-specific code style or contribution conventions. I also did not have much time to review the code style deeply, so I am open to adjusting the implementation if needed.

I tested this fork in my project and confirmed that it fixes the autopatch recursion issue with humachi/chi. However, my original issue was not about preserving context values for the internal GET/PUT requests, so I cannot be 100% sure that this does not affect the behavior intended by the previous PR. The goal of this change is to preserve the incoming context while filtering out the chi routing state that causes the nested request to be routed incorrectly.